In asymmetric key encryption, a host device, such as a server, may securely communicate with another host device, such as a client, by using a private encryption key-public encryption key pair. The server may provide the client with a copy of its public key with the knowledge that other entities, such as hackers or other malicious actors, may also receive copies of the server's public key by “listening” in on communications between the server and the client. Using the server's public key, the client may encrypt data that it transmits to the server such that the encrypted data may be decrypted only using the server's private key. Provided the server keeps its private key secret, only the server will be able to decrypt the public-key-encrypted data from the client.
Private keys may also be used to demonstrate message integrity and end-point authentication by, for example, encrypting a message or hash string of a message using the key holder's private key, a process known as “digitally signing.” Although any party with access to the key holder's public key may be able to decrypt the digital signature to verify the message's integrity, since only the key holder has access to the corresponding private key, it may be demonstrated that only the key holder could have digitally signed the message. This feature of asymmetric key encryption also presupposes that the key holder maintains its private key in secret.
In some circumstances, however, it may be beneficial for a private key holder to entrust a third party entity with a copy of its private key. For example, the key holder may wish to entrust a third party mitigation service provider with a copy of its private key to enable the mitigation service provider to intercept and decrypt secure communications directed to the key holder's servers in the event of a Secure Sockets Layer (“SSL”) denial-of-service (“DoS”) or other form of cyber attack, a novel technique that is further described in co-pending application Ser. No. 12/982,520, which is also assigned to this assignee.
The owner or holder of the private key has essentially two options for providing the mitigation service provider with a copy of its private key. The key holder may provide the mitigation service provider with a copy of the key in advance of any attack on its servers, for example, upon the commencement of the contract between the key holder and the mitigation service provider to provide SSL DoS mitigation services to the key holder. While this approach allows the mitigation service provider to quickly utilize the key holder's private key to mitigate against the SSL DoS attack, it also introduces various security and audit problems.
In particular, the mitigation service provider's possession of the holder's private key may allow the mitigation service provider to impersonate the key holder and thus to potentially gain access to encrypted communications—for example, containing customers' credit card information—intended for the key holder's servers. Or, even if the mitigation service provider does not engage in fraudulent behavior using the holder's private key, an employee of the mitigation service provider or an external hacker could potentially gain access to the private key and thus impersonate the key holder. Because of these and other risks that flow from potentially misappropriated private keys, many organizations have strict policies regarding access to and copies of their private keys. And, consequently, many organizations keep, or may be required contractually or by law to keep, detailed records regarding any internal or third-party possession of or access to copies of their private keys.
The advanced placement of a key holder's private key with a mitigation service provider may conflict with security policies that may prohibit providing a third party with a copy of the holder's key in the absence of an attack or other need by the third party to access the key. Moreover, because the mitigation service provider's internal procedures for storing, copying, and protecting the private key may not be known, it may be difficult for the key holder to maintain a complete and accurate audit trail of all actions that may be taken by the mitigation service provider with respect to the key.
For these and other reasons, the key holder may elect instead to provide the mitigation service provider with a copy of its private key only in the event of an actual cyber attack. While this approach may avoid some of the above-described security and audit problems, it too suffers from a number of disadvantages. Most importantly, in the event of an actual cyber attack, it may be difficult or impossible to quickly provide the mitigation service provider with a copy of the private key. For example, technical difficulties introduced by the cyber attack may collaterally affect other devices or systems from which the key holder would need to access and export its private key.
Also, the same strict policies regarding granting third-party access to the holder's private key and maintaining appropriate audit trails for the key may prevent the key holder from being able to access or distribute the key until various procedural steps, including potentially obtaining authorization from multiple, separate corporate custodians, have been followed. This too may prevent the key holder from quickly providing a copy of its private key to the mitigation service provider to enable the mitigation service provider to expeditiously intervene and blunt the attack. Moreover, in either case, there may not exist an efficient and secure manner for distributing the key to the mitigation service provider, since conventional means for distributing private keys, such as by e-mail or by sending a storage device by mail, may present additional security and audit problems.
There is therefore a need for methods and systems for enabling a private key holder to quickly and securely provide a third party with access to the holder's private key in the event of a cyber attack, or other need for the third party to access the key, while simultaneously limiting and regulating the third party's access to the private key in other circumstances.